Computerized method and system for implementing distributed applications

ABSTRACT

A computerized method and a system for implementing in a network distributed applications, comprising instructions for a computer process which are executable on different locations in the network, is proposed. The instructions include an assert-command and/or a release-command.

TECHNICAL FIELD

The present invention is related to a method and system for implementingdistributed applications in a computer network. In general, theapplications are executable on any location in the network.

BACKGROUND OF THE INVENTION

Computers and devices are connected via networks where applications arebeing processed and executed. Different architectures and programminglanguages for their operation are known. Conventional programminglanguages such as Pascal, C, or Java, do not provide any standard meansfor identifying location requirements. In classical distributed computerapplications such dependencies are identified by the applicationprogrammer who splits the overall application into integral parts, suchas ‘client’ and ‘server’, programs these parts separately and installsthem at a required position or on a required device. Communicationsbetween those parts is provided by either message-passing, remoteprocedure calls or, in the case of object-oriented programminglanguages, by remote method invocations.

Agent-technology or mobile code programming has recently introducedanother method for realizing distributed systems. The need fordeveloping the overall application in separate parts has been removed,and replaced by simple language primitives, such as the ‘GO’ command,which move the application in its entirety to another location. It hasbeen shown that this simplifies the programming of such applicationssince the application can be written with a single flow of control.

U.S. Pat. No. 5,603,031 describes a system and a method for distributedcomputation based upon the movement, execution, and interaction ofprocesses in a network. An agent process controls its movement from oneplace process to another within the network by using a ticket and sendsclones of the agent process to several place processes simultaneously.

This simple programming model which is used for common systems has anumber of limitations. First, while a single flow of control allowssimple design and implementation, it is too rigid to allow foroptimizations such as the exploitation of parallelism at run-time.Further, the structure prescribes a fixed location-dependency; if therequested location is unavailable, the execution of an application musthalt. This is negative since it is common that for most portions of theprogramming code the location at which they are executed is irrelevant.Furthermore, the simple ‘GO’ primitive is only usable to indicatelocation dependencies, and the point at which a ‘GO’ must be executedmust be defined at compile-time.

OBJECT AND ADVANTAGES OF THE INVENTION

It is an object of the present invention to provide a method and systemfor implementing distributed applications in a network.

It is another object of the present invention to provide more locationflexibility for networks.

It is a further object of the present invention to provide a simplemethod for the execution of distributed applications in a network.

It is still a further object of the present invention to optimize theprocesses in a network.

The method and system for implementing distributed applications in anetwork according to claim 1 and claim 9 shows the advantage that moreefficiency can be obtained, because only the necessary parts of anapplication are transferred and executed on relevant and suitablelocations, and those should only be transferred when necessary. Thisoptimizes transferring-, connecting- and processing-times, whichimplicitly reduces costs. Furthermore, the method provides enoughflexibility to a runtime system to allow more freedom of action, i.e.flexible and efficient execution, and is thus a remedy to the rigidstructure demanded by conventional agent-programming or mobile code.Such efficiency and flexibility cannot be achieved by conventionalmethods of distributed-application programming, such as client/server ortraditional agent system. It is therefore an object of the invention toovercome the problems of the state of the art.

In the dependent claims various modifications of and improvements to themethod for implementing distributed applications are contained.

When a location is identified by giving a location identifier whichcomprises for the location its definite position or a functionalityrequired for execution at the location or a parameter which fromavailable parameters is to be chosen optimal for the execution at thelocation or by giving an address where to find said location identifier,then the advantage occurs that the proposed method allows a wide rangeof location identification possibilities. The address of a locationwhere to execute an application is hence no longer bound to a fixedposition, but the choice of a location is herewith rendered moreflexible.

The present invention makes use of additional instructions, whichinclude an assert-command which can be used wherever it is to beeffected that the subsequent instructions are executed at an identifiedlocation. No other command for the execution on another location isneeded, which guarantees for simplicity, uniformity and correctexecution. The ‘GO’ command becomes unnecessary, which is an advantagefor future developments and applications.

When the instructions of an application includes differentassert-conmmands, such as ASSERT, INSIST and PREFERRED, then theadvantage occurs that the applications get more flexibility and freedomof action. In case of non-availability of a location for the executionof the application, a first assert-commnand type (ASSERT) indicates alocation and the programs willingness to suspend its executiontemporarily. A second assert-command type (INSIST), on the other hand,might terminate the application in such instances. Therefore, theprocess of the application doesn't wait but rather aborts execution. Athird assert-command type (PREFERRED) continues by executing thesubsequent instructions at the previously used location, which has theadvantage that the application carries on, even though the preferred iscurrently unavailable. Several assert-command types are creatable andusable for distributed applications, which shows the flexibility andadaptability of the inventive method for distributed applications in anetwork.

The assert-command types can point to identified locations of differentlocations, whereby the identified locations are choosable “ad libitum”,which means that the identified locations are selectable without anypreferences, or in the other case, the identified locations arearrangable and selectable in a predetermined preference-orderedsequence, which gives much room and flexibility to move an application.The execution of an application and the processes in a network cantherewith be optimized and adapted.

A runtime system is usable to move the applications to identifiedlocations in a network and executes the instructions. In the case of arelease-command the choice of a location whereto the application ismoved, is then dependent on system- and/or state conditions. Thisprovides more freedom of action for the runtime system, which is nowable to use the available resources of the network.

SUMMARY OF THE INVENTION

The invention provides a general and flexible method and system forimplementing a distributed application in a network.

The present invention for implementing a distributed application in anetwork describes a method and system which allow the temporaryassertion of position-, device- or service-dependencies and can be usedin applications to describe the required location behavior abstractlyand in an intuitive manner. Instructions for a computer process whichare executable on different locations in the network comprising anassert-command and/or a release-command. The assert-command points to anidentified location of the different locations, which effects that itssubsequent instructions are to be executed at the identified location.The release-command effects that the execution of its subsequentinstructions is not bound to an identified location.

The problem from the state of the art that more than one location has tobe used from one application is still considered valid, whereby thepositions, devices or services are not fixed according to an allocatedaddress and even the swap times, i.e. when an application moves toanother location, are not predetermined.

DESCRIPTION OF THE DRAWINGS

The invention is described in detail below with reference to thefollowing schematic drawings.

FIG. 1 shows a schematic diagram of an application according to thepresent invention.

FIG. 2 shows a schematic illustration of a network with differentlocations and connections.

All the figures are for the sake of clarity not shown in realdimensions, nor are the relations between the dimensions shown in arealistic scale.

DETAILED DESCRIPTION OF THE INVENTION

In the following, the various exemplary embodiments of the invention aredescribed.

Herewith are introduced two command primitives which either assert theavailability or presence of a position, device or service, or release apreviously made assertion. For illustration purposes, these primitivesare herein called ‘ASSERT’ and ‘RELEASE’. The primitives may be calledagainst either positions of type ‘POSITION’ or devices of type ‘DEVICE’or services of type ‘SERVICE’. The semantics of the primitives can besummarized as follows:

a location ASSERT determines that the instructions following the ASSERTcall must be executed at the asserted location,

a location RELEASE indicates that the instructions following the RELEASEcall might be executed on any place.

Furthermore, other primitives can be provided, for example:

a location PREFERRED indicates that the instructions following thePREFERRED call are preferably executed at a preferred location, or

a location PROXIMITY indicates that physical or network proximity to agiven location is required, or

a location LOAD indicates that a location where a minimum load ispresent is required, or

a location SPEED indicates that a location with special processing timeor speed is required, or

a location SECURITY indicates that a connection to a given location in asafe manner is required.

Depending on the requirements, many more primitives can be created andprovided. The semantics of the primitives is therefore freelychooseable.

A location is identified by giving a location identifier which comprisesfor the location its definite position or a functionality required forexecution at the location or a parameter which from available parametersis to be chosen optimal for the execution at the location or by givingan address where to find the location identifier. A definite positionfor a server, device or service may be known, this makes the addressingand the finding of a location in a network simple.

Also a functionality can be required by the user, by the system or bythe application. It can be required a special device or a device with afeature or even a service, like printing. A CD-player with random playor a special mathematics processor may be required for the execution andtherefore described by the functionality, which then is to be found in anetwork.

A location can also be identified by a location identifier whichcomprises a parameter, for instance by a parameter like LOAD, SPEED orSECURITY which are mentioned above. The system may be designed that itis able to choose by itself for a parameter the optimal value orvalue-range for the execution in that it follows predetermined rules,e.g. representing a behavior which can be assumed to be desired. Forinstance, when the load on a location should be low, the parameter LOADis therefor chosen to be optimized for the execution. Naturally, a lowload is desired which the runtime system might have implemented asautomatic preferred direction of optimization. Alternatively thepreferred direction can be given by a programmer, user or the like. Itis a natural goal to be able to do things quickly. The speed cantherefor be chosen as fast as possible to be optimal for theapplication's requirements and the user's needs. The parameter is henceSPEED and the runtime system will automatically tend to find a locationwith the highest processing speed value. As example is given:

LOCATION v=LOCATION (SPEED, min 50),

whereby the parameter SPEED is introduced to the runtime system whichhence seeks access to a location with maximum processing speed or atleast processing speed value 50. For the security, a special certificateor a security-level might be chosen in a range to be optimal for theexecution. The security-level may also correspond to an issuingauthority. An example with the parameter SECURITY for a location whichrequires a security-level “3” is given by

LOCATION sl=LOCATION (SECURITY, “3”)

and for a location which needs a special issuing authority

LOCATION sa=LOCATION (SECURITY, “VISA”)

can be used.

In the following examples, the used primitives are called ‘ASSERT’ and‘RELEASE’. For the illustration, a simple self-explaining syntax is usedwithin the following code segment:

//Code Block A

[1] LOCATION a=LOCATION (POSITION, “piot.zurich.ibm.com”);

[2] a.ASSERT ( );

//Code Block B

[3] a.RELEASE ( );

//Code Block C

In the above example, a location assertion and release is embeddedwithin three Code Blocks termed A, B, C. The handling of these calls canbe implemented either at compile time or preferably at run time, asassumed in the following.

At code line [1], a particular machine location is defined. For example,the runtime system verifies the existence of the desired location orestablishes a communication link in preparation for any communicationtasks which could reasonably be expected.

At code line [2], the previously defined location is asserted by ASSERT.The runtime system interprets now the requirement that, the followinginstruction lines (Code Block B) are to be executed at the assertedposition “piot.zurich.ibm.com”.

At code line [3], the location constraint is being released. This is theindication to the runtime system that Code Block C is not bound to thepreviously asserted location. Hence, the runtime system is now free tomove the application and execute the instructions following the RELEASEto any other location.

Similarly, the same primitives might be executed against devicedescriptions such as in the second example, whereby a functionalityherein is expressed as device:

[5] LOCATION d=LOCATION (FUNCTIONALITY, “mpeg_player”);

[6] d.ASSERT ( );

//Code Block F

[7] d.RELEASE ( );

The example indicates that a functionality respectively a device in codeline [5] with location identifier “mpeg_player” has to be available atthe location d. At code line [6], the previously defined location d isasserted by ASSERT. The runtime system interprets then the requirementthat the following instruction lines, which start here with Code BlockF, are to be executed at the asserted location d identified by locationidentifier “mpeg_player”. At code line [7], the location constraintrespectively device constraint is being released. This is the indicationto the runtime system that the following instruction lines are not boundto the previously asserted location.

Feedback might be provided by such primitives to an application to allowreasonable abort-modes. An ASSERT may imply a RELEASE of a previouslyasserted location.

Referring now to FIG. 1, which shows a general schematic diagram of anapplication (11.1, 11.2, 11.3), which is respectively executed onlocation 1, 2 and 3, further details are described according to theprocessing of the application (11.1, 11.2, 11.3) depicted by a dottedline and arrows. The schematic diagram starts on the top of the left boxon location 1 with RELEASE 8 as a release-command. This release-commandRELEASE 8 effects that the execution of the subsequent instructions 9depicted as block 9 are not bound to an identified location. It istherefore then possible for the runtime system to move the application11.1 to a further location, like location 2 or 3, or carry on with theexecution of the application 11.1 on location 1, as depicted in the leftbox. The vertical dotted line shows the processing of the application11.1. An assert-command ASSERT (LOC 2) 4 following block 9 inapplication 11.1 denotes the latest instance when the application 11.1must be moved by the runtime system to location 2 to ensure subsequentinstruction lines following the ASSERT (LOC 2) 4 command are beingexecuted at location 2. The runtime system interprets then therequirement that the instructions following at the beginning of block 5have to be executed at the asserted location 2 and no longer at location1. The arrow from location 1 to location 2 shows the latest possibilityfor the runtime system to move the application 11.1 to location 2. Thevertical dotted line on the left side of the right box shows also theprocessing of the application 11.2, which is then situated and executedon location 2. Followed by another RELEASE 8, the instructions of block9 from application 11.2 on location 2 are not location-dependent, whichmeans that the application 11.2 might be executed on another locationthan location 2. With the following assert-command ASSERT (LOC 3) 4 theapplication 11.2 is then moved by the runtime system to location 3(depicted by the arrow from location 2 to location 3), where theapplication 11.3 according to the instructions of the block 6 isexecuted. Block 6 has to be executed on the asserted location 3, whichis indicated by ASSERT (LOC 3) 4. Furthermore, the application 11.3which includes block 7, asserted by ASSERT (LOC 1) 4, has to be moved(depicted by the arrow from location 3 to location 1) and executed onthe asserted location 1. The following release-command RELEASE 8 onlocation 1, depicted at the bottom of the left box, effects that theexecution of the application 11.1 by its subsequent instructions,depicted as block 10, is released and not bound to an identifiedlocation. Here, the application 11.1 is further executed on location 1.In these last descriptions the term “has to be moved” refers to thelatest possible point in time when the runtime system has to migrate theapplication. Earlier migration is possible, but not before the previousRELEASE command.

FIG. 2 shows a schematic illustration of a network 20 with differentlocations and connections for a better understanding of FIG. 1. Theboxes represent respectively a location 1, a location 2 and a location 3corresponding to the locations 1, 2, 3 of FIG. 1.

The locations 1, 2, 3 are connected and might have further connectionsindicated by the dotted lines.

Two characteristic examples with self-explaining instruction codes areaddressed in the following.

EXAMPLE I Remote DB Access

The following example “Remote DB (database) Access” demonstrates dynamicadaptation of a runtime environment which leads to improved codeefficiency and flexibility and is concerned with an application on aclient machine interacting with a remote database server. Inconventional client/server systems, the client part would implement auser interface on a local client machine, whereas the server componentwould reside with the database remotely. The client might be implementedas follows:

Print “Name?”

Input user_name

Contact Server

Request server to verify user_name with regard to DB

if (server reports that user_name is already entered in DB)

terminate

else

Print “Address?”

Input address

. . .

The server code (not shown) is developed separately. Agent-based systemsimprove this by allowing the application to be developed as a singlethread of execution. An agent implementation with the same function likein the previous example might be implemented as:

Print “Name?”

Input user_name

GO DB_server

Check user_name with regard to now local DB

if (user_name is already entered in DB)

terminate

else

GO client_machine

Print “Address?”

Input address

. . .

In both the client/server methodology and the agent-based approach itmust be decided a-priori that the check of the user's name with regardto the database is to be performed. If the client's networkingenvironment is such that communications with the database server mightbe temporarily unavailable, it could be advantageous to skip theverification process and/or tolerate the inconvenience of enteringaddress data twice. Making the client/server code to adjust its behaviordynamically would require low-level access to the communications andnetworking subsystem which are not only cumbersome to include in theapplication code but also hamper the application's portability andmaintainability. The GO command is too rigid and inflexible to allow anyadaptability.

Using the primitives ‘ASSERT’ and ‘RELEASE’, the task is solved byallowing the runtime system to adapt to the environment, such as:

LOCATION clientloc=new LOCATION (“Client machine”);

LOCATION dbloc=new LOCATION (“DB machine”);

clientloc.ASSERT ( );

Print “Name?”

Input user_name;

clientloc.RELEASE ( );

if (dbloc.PREFERRED ( )==GRANTED)

Check user_name with regard to DB

dbloc.RELEASE ( );

If (user_name is already entered in DB)

terminate

clientloc.ASSERT ( );

Print “Address?”

Input address

clientloc.RELEASE ( );

Since the instructions are given in their full syntax, the code appearshere longer than in the previous examples. However, the runtime systemis free to relocate the code from the client's machine to the preferreddatabase location if this is achievable given the current connectivitystate of the client.

EXAMPLE II A Distributed CD Player

The next example “A Distributed CD Player” demonstrates the ability of aruntime system to dynamically relocate the execution location of asingle application to permit access to required services or requiredlocations, while to perform computationally complex operations atmachines that are only lightly loaded or have specialized hardware thatmake them particularly suited for the tasks of the applications. Thefollowing application implements a music-CD player:

[20] LOCATION cd=new LOCATION (SERVICE, “CLASSIC CD MOZART”);

[21] cd.ASSERT ( );

//read soundtrack

[22] cd.RELEASE ( );

//decode soundtrack

[23] LOCATION loc=LOCATION (POSITION “my machine”);

[24] loc.ASSERT ( );

//play soundtrack

[25] loc.RELEASE ( );

In this example, the application demands that the runtime system locatesan available server that is willing to offer a particular CD as aservice, like the requested CD in code line [20]. The defined locationis asserted by ASSERT at code line [21]. Once the runtime system hasaccess to the respectively location, the next instruction is executedwhich reads the soundtrack of the CD. After this process is finished,the application indicates to the runtime system that the service is nolonger required. The application then starts decoding the soundtrack, acomputationally expensive task. Although the application has notdemanded so, the runtime system is now free to move the application toanother location (host) and continue execution there at any time itdecides to do so. The RELEASE primitive at code line [22] has indicatedthat no particular location is required, but does not indicate when orif at all the code has to be moved, it merely indicates the ‘earliesttime’ when a relocation ‘may’ happen. Once decoding is completed, theapplication indicates that it wishes to play the soundtrack at aparticular machine, like on “my machine” now described in code line[23], and the runtime system is requested to grant this demand. TheASSERT primitive in code line [24] does not indicate when the code hasto be relocated to the indicated machine, merely the ‘latest time’ whenthis ‘must’ be done. With the RELEASE primitive at code line [25] thelocation constraint is being released.

What is claimed is:
 1. A computerized method for implementing in anetwork (20) a distributed application (11.1, 11.2, 11.3) comprisinginstructions for a computer process which are executable on differentlocations (1, 2, 3) in said network (20), said instructions including:an assert-command (4) pointing to an identified location (2, 3, 1) ofsaid different locations (1, 2, 3), which command effects that itssubsequent instructions (5, 6, 7) are to be executed at said identifiedlocation (2, 3, 1); and/or a release-command (8), which effects that theexecution of its subsequent instructions (9, 10) is not bound to any ofsaid locations (1, 2, 3).
 2. The computerized method according to claim1, wherein the location (1, 2, 3) is identified by giving a locationidentifier which comprises of said location (1, 2, 3) its definiteposition or a functionality required for execution at said location (1,2, 3) or a parameter whose value is to be chosen optimal for saidexecution at said location (1, 2, 3) or by giving an address where tofind said location identifier.
 3. The computerized method according toclaim 1, wherein the instructions include the assert-command (4),whereby said assert-command (4) is used wherever it is to be effectedthat its subsequent instructions (5, 6, 7) are executed at theidentified location (2, 3, 1).
 4. The computerized method according toclaim 1, wherein the instructions include the assert-command (4),whereby in case of non-availability of the location (1, 2, 3) for theexecution, the application does not continue, which realizes a firstassert-command type (ASSERT), or suspends, which realizes a secondassert-command type (INSIST), or continues by executing the subsequentinstructions at the previously used location, which realizes a thirdassert-command type (PREFERRED).
 5. The computerized method according toclaim 4, wherein several of the assert-command types are used in theapplication (11.1, 11.2, 11.3).
 6. The computerized method according toclaim 4, wherein the assert-command (4) points to at least one anotheridentified location (2, 3, 1) of the different locations (1, 2, 3) andthat either one of said pointed-to identified locations (2, 3, 1) ischoosable ad libitum or that said identified locations (2, 3, 1) arearranged in a predetermined preference-ordered sequence.
 7. Thecomputerized method according to claim 1, wherein a runtime system inthe case of the assert-command (4) moves the application (11.1, 11.2,11.3) or parts thereof to the identified location (2, 3, 1) and/or inthe case of the release-command (8) leaves the choice of the location(1, 2, 3) whereto said application (11.1, 11.2, 11.3) is moved, to atleast one system- and/or state-dependent condition, and, having saidapplication (11.1, 11.2, 11.3) at said identified location (2, 3, 1) orchosen location (2, 3, 1) executes the instructions.
 8. The computerizedmethod according to claim 1, wherein said instructions (4-10) areJava-based.
 9. A system for implementing in a network (20) distributedapplications (11.1, 11.2, 11.3) with instructions of a computer processwhich are executable on different locations (1, 2, 3) in said network(20), comprising at each location: a processor for executing saidinstructions; a memory unit coupled to said processor, for storing saidinstructions; an interface of said processor to said network; a runtimesystem, managing the execution of said instructions; which include: a.an assert-command (4) pointing to an identified location (2, 3, 1) ofsaid different locations (1, 2, 3), which command effects that itssubsequent instructions (5, 6, 7) are to be executed at said identifiedlocation (2, 3, 1); and/or b. a release-command (8), which effects thatthe execution of its subsequent instructions (9, 10) is not bound to anyof said locations (1, 2, 3).
 10. A computer-readable medium encoded witha computerized method of implementing in a network (20) distributedapplications (11.1, 11.2, 11.3), comprising instructions for a computerprocess which are executable on different locations (1, 2, 3) in saidnetwork (20), the method improving the location flexibility in saidnetwork (20) in that said instructions include: an assert-command (8)pointing to an identified location (2, 3, 1) of said different locations(1, 2, 3), which command effects that its subsequent instructions (5, 6,7) are to be executed at said identified location (2, 3, 1); and/or arelease-command (8), which effects that the execution of its subsequentinstructions (9, 10) is not bound to any of said locations (1, 2, 3).